![【アップデート】Security Hubコントロール [Config.1]のチェック観点から「AWS Configで使用されるIAMロールのチェック」を除外できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-refcat-img-cea52bc8a6ec5cad9021b38df4a08b9e/24c76ee7c1ae7aa7f9676a59c77f8702/aws-security-hub)
【アップデート】Security Hubコントロール [Config.1]のチェック観点から「AWS Configで使用されるIAMロールのチェック」を除外できるようになりました
2024.08.22あしざわです。
皆さんはSecurity Hub運用、やっていますか？
今回紹介するアップデートは、Security Hubの運用をしている一部の方に刺さる内容です。
2024/8/15 にAWS Security Hubコントロールの1つである[Config.1] AWS Config should be enabled and use the service-linked role for resource recordingに関するアップデートがありました。
その内容は、Security Hubのチェック項目(コントロール)の1つである [Config.1]のカスタムパラメーターが追加された、といったものです。このパラメーターの変更によって、[Config.1]がAWS環境をチェックする基準を調整できるようになりました。
本件は、Security Hubの公式ドキュメントにあるDocument Historyの2024/8/15の内容から確認できます。
This control checks whether AWS Config is enabled, uses the service-linked role, and records resources for enabled controls. Security Hub added a custom control parameter named includeConfigServiceLinkedRoleCheck. By setting this parameter to false, you can opt out of checking whether AWS Config uses the service-linked role.
参考: https://docs.aws.amazon.com/securityhub/latest/userguide/controls-change-log.html
(機械翻訳)
このコントロールは、AWS Configが有効かどうかをチェックし、サービスリンクされたロールを使用し、有効なコントロールのリソースを記録します。Security Hubは、includeConfigServiceLinkedRoleCheckというカスタムコントロールパラメータを追加しました。このパラメーターをfalseに設定することで、AWS Configがサービスリンクされたロールを使用するかどうかのチェックをオプトアウトできます。
まとめ
本件の背景とアップデート内容をまとめたものがこちら
- 背景
- [Config.1]はこちらの3点をチェック観点としている。
- AWS Config(レコーダー)が有効化されているか
- 有効化されているすべてのSecurity Hubコントロールに対応するすべてのリソースタイプがConfigレコーダーで記録できているか
- AWS ConfigのIAMロールとしてサービスリンクロール(
AWSServiceRoleForConfig)が指定されているか
- [Config.1]はこちらの3点をチェック観点としている。
- アップデート内容
- [Config.1]のカスタムパラメータに
includeConfigServiceLinkedRoleCheckが追加された。- 許可されているパラメータは
trueorfalseで、デフォルト値はtrue - パラメータが
trueのとき、チェック観点の3.が評価対象となる。 - パラメータが
flaseのとき、チェック観点の3.が評価対象外となる。
- 許可されているパラメータは
- [Config.1]のカスタムパラメータに
これまではどうだったのか
Security Hubコントロールの[Config.1]は、こちらの3つのチェック観点から評価されます。すべての観点が満たされていた場合にPASSED(成功)となります。
- AWS Config(レコーダー)が有効化されているか
- 有効化されているすべてのSecurity Hubコントロールに対応するすべてのリソースタイプがConfigレコーダーで記録できているか
- AWS Configのサービスリンクロール(
AWSServiceRoleForConfig)が作成されているか
※以降それぞれを、1.のチェック観点 、2.のチェック観点 、3.のチェック観点 と呼びます。
1.のチェック観点では「該当のリージョンでConfigレコーダーが有効化されているか」を評価しています。
2.のチェック観点では「該当のリージョンでSecurity Hubで有効化されているコントロールに必要な AWS Config のリソースの記録がオンになっているか」を評価します
3.のチェック観点は「該当のリージョンのAWS Config のIAMロールにサービスリンクロール『AWSServiceRoleForConfig』が使用されているか」を評価します。
詳細は以下ブログにも記載されているため、こちらも合わせてご覧ください。
これまでの悩み
3.のチェック観点は、先日2024/6/10にリリースされたコントロール変更によって追加された新しい項目です。
This control checks whether AWS Config is enabled and AWS Config resource recording is turned on. Previously, the control produced a PASSED finding only if you configured recording for all resources. Security Hub updated the control to produce a PASSED finding when recording is turned on for resources that are required for enabled controls. The control has also been updated to check whether the AWS Config service-linked role is used, which provides permissions to record necessary resources.
参考: https://docs.aws.amazon.com/securityhub/latest/userguide/controls-change-log.html
(機械翻訳)
このコントロールは、AWS Config が有効で、AWS Config リソースの記録がオンになっているかどうかをチェックします。以前は、すべてのリソースに対して録画を設定した場合にのみ、このコントロールはPASSED検出結果を生成していました。Security Hubは、有効なコントロールに必要なリソースの記録がオンになっている場合に、PASSEDファインディングを生成するようにコントロールを更新しました。また、このコントロールは、必要なリソースを記録する権限を提供する AWS Config サービスにリンクされたロールが使用されているかどうかをチェックするように更新されました。
上記に記載がある通り、このチェック内容は「AWS Configで使用されるロールとして、AWS Configのサービスリンクロール(AWSServiceRoleForConfig)が使用されているか」というものです。Configで使用されるロールとして AWSServiceRoleForConfig 以外が設定されていても違反となってしまいます。
クラスメソッドメンバーズでは、AWSアカウント発行時にAWSアカウントの運用に最低限必要なAWSリソースを自動作成しており、AWS Configで利用されるロールには独自ロール(cm-config-role-all-regions)を設定しています。
[Config.1]のチェック観点では独自ロールの指定は許容されないため、クラスメソッドメンバーズで発行したAWSアカウントでSecurity Hubを有効化すると[Config.1]のステータスは常にFAILEDとなってしまう状態でした。
Security Hub運用においてはこの状態はよろしくないため、これまでは[Config.1]で検知したアラートを抑制したり、無効化する対応が求められていました。
どのように変わったのか
アップデートによって[Config.1]にカスタムパラメーター(includeConfigServiceLinkedRoleCheck)が追加されました。
includeConfigServiceLinkedRoleCheckのデフォルト値は true で、この状態だと3.のチェック観点が有効になっています。
このパラメーターを false に変更することで3.のチェック観点を無効化し、1.および2.のチェック観点のみで[Config.1]を評価できるようになっています。
3.のチェック観点を無効化できるということは、クラスメソッドメンバーズのAWSアカウントのような「AWS Configで使用されるロール」を独自ロールに指定している環境でも[Config.1]の項目に準拠できるようになります。
つまり、クラスメソッドメンバーズにおいてSecurity Hubを運用する場合の必須のパラメータ設定というわけです。
設定してみた
クラスメソッドメンバーズのAWSアカウントを利用して、実際に[Config.1]の 3.のチェック観点がオプトアウトできるか、確認してみましょう。
まずはAWS Configの設定を確認しました。レコーダーの記録は有効、記録戦略には「〜すべてのリソースタイプを記録」が設定されており、Security Hubコントロールのすべての項目でチェックされるようにしています。また、AWS ConfigのIAMロールにはcm-config-role-all-regionsが指定されていることがわかります。
続いて、変更前のSecurity Hubの状態を確認します。東京リージョン・バージニア北部リージョンの両方で、[Config.1]のコンプライアンスのステータスが FAILED であると確認できました。
現在のステータスが確認できたので、東京リージョンの[Config.1]のカスタムパラメータを変更してみます。
[Config.1]のパラメータタブの設定をクリックします。
パラメータ設定を 本当(True) から 偽(False) に変更し、変更の理由を任意のものに指定。保存をクリックします。
※本当や偽は誤翻訳だと思われるのでそのうち修正されると思われます
変更直後は以下のように更新中と表示されていましたが、すぐに設定が反映されました。
その後、数時間後Security Hubの再チェックが実行され、東京リージョンのコンプライアンスのステータスがPASSEDに変更されていることが確認できました。
※カスタムパラメータを変更していないバージニア北部リージョンはFAILEDのままでした
注意点
実際のワークロードで設定変更を行う際には、以下の点に気をつけてください。
- カスタムパラメータの設定はリージョンごとに設定する必要があります。Security Hubを利用している全リージョンで合わせて設定変更しておきましょう。
- [Config.1]のスケジュールタイプ(チェック頻度)は「Periodic(定期)」なので、設定変更後すぐに再チェックが実行されません。1日〜半日程度時間を空ける必要がある点に注意してください。
- カスタムパラメータの設定をFalseにしても他のチェック観点(1.や2.)で違反となればPASSEDのステータスになりません。パラメータ変更後に想定した結果にならなかった方は他のチェック観点についても確認するようにしてください。
最後に
Security Hubのアップデートによって追加された[Config.1]のカスタムパラメータ設定を試してみました。
[Config.1]は複数の条件でチェックされているため、Security Hubコントロールの中でも内容の理解に至るまでの難易度が高いコントロールの1つだと思います。この記事と合わせて、以下記事などを参考に理解を深めていただくと色々捗るかなと思いました。
本記事が、これまで[Config.1]の対応に困っていた方のお役に立てれば幸いです。
以上です。
![【Security Hub修復手順】[Athena.4] Athena ワークグループでは、ログ記録を有効にする必要があります](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-764c44f07bcd41184fe62a432ae120ab/512a4cdcd05a0ed3ddea950fdf619fa0/amazon-athena)
![[Amazon Bedrock] RAG利用時の選択肢「Kendra」と「Bedrock Knowledge Bases」を比較する](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e3065182082062711612153bbdcf1d96/c04359de689df2f56eb066576ab63fb5/amazon-bedrock)
